Voice and data encryption method using a cryptographic key split combiner

ABSTRACT

A cryptographic key split combiner, which includes a number of key split generators ( 42, 48 , and  56 ) for generating cryptographic key splits ( 32, 34, 36, 38 , and  64 ) and a key split randomizer for randomizing the cryptographic key splits to produce a cryptographic key ( 62 ), and a process for forming cryptographic keys. Each of the key split generators ( 42, 48  and  56 ) generates key splits ( 32, 34, 36, 38 , and  64 ) from seed data ( 40, 44, 46, 50, 52, 54, 58 , and  60 ). The key split generators may include a random split generator ( 42 ) for generating a random key split ( 32 ) based on reference data ( 40 ) and encryption date/time ( 44 ). Other key split generators may include a token split generator ( 48 ) for generating a token key split ( 34 ) based on label data ( 46 ) and organization data ( 50 ), a console split generator ( 56 ) for generating a console key split ( 36 ) based on current maintenance data ( 52 ) and previous maintenance data ( 54 ), and a biometric split generator for generating a biometric key split ( 38 ) based on biometric data ( 58 ). All splits may further be based on static data, which may be updated, for example by modifying a prime number divisor of the static data. The label data may be read from a storage medium, and may include user authorization data. The label data may be associated with label categories and subcategories of addresses, which are meaningful to a user who is specifying or determining the intended recipient(s) of the encrypted information or object. An array associated with a software component object may use key splits ( 32, 34, 36, 38 , and  64 ) which determine which methods and properties are allowed and control access to the memory address for those allowed methods and properties. The resulting cryptographic key ( 62 ) may be, for example, a stream of symbols, at least one symbol block, or a key matrix.

This application claims the benefit of Provisional Application No.60/124,086, filed Mar. 11, 1999.

CROSS-REFERENCE TO RELATED PATENTS AND APPLICATIONS

This disclosure incorporates the entire written descriptions of U.S.Pat. No. 5,410,599, entitled “Voice and Data Encryption Device,” whichissued on Apr. 25, 1995 to CROWLEY et al., and U.S. Pat. No. 5,375,169,entitled “Cryptographic Key Management Method and Apparatus,” whichissued on Dec. 20, 1994 to SCHEIDT et al.

This is related to U.S. Pat. No. 5,787,173, entitled “Cryptographic KeyManagement Method and Apparatus,” which issued on Jul. 28, 1998 toSCHEIDT et al. This is also related to the following co-pending U.S.patent applications: Ser. No. 09/023,672, entitled “Cryptographic KeySplit Combiner,” filed on Feb. 13, 1998 by SCHEIDT et al.; Ser. No.09/874,364, entitled “Cryptographic Key Split Combiner,” filed on Jun.6, 2001 by SCHEIDT et al.; Ser. No. 09/917,795, entitled “CryptographicKey Split Combiner,” filed on Jul. 31, 2001 by SCHEIDT et al.; Ser. No.09/917,794, entitled “Cryptographic Key Split Combiner,” filed on Jul.31, 2001 by SCHEIDT et al.; Ser. No. 09/917,802, entitled “CryptographicKey Split Combiner,” filed on Jul. 31, 2001 by SCHEIDT et al.; Ser. No.09/917,807, entitled “Cryptographic Key Split Combiner,” filed on Jul.31, 2001 by SCHEIDT et al.; Ser. No. 09/992,529, entitled “CryptographicKey Split Combiner,” filed on Nov. 20, 2001 by SCHEIDT et al.; Ser. No.09/205,221, entitled “Access Control and Authorization System,” filed onDec. 4, 1998 by SCHEIDT et al.; Ser. No. 09/388,195, entitled“Encryption Process Including a Biometric Input,” filed on Sep. 1, 1999by SCHEIDT; Ser. No. 09/418,806, entitled “Cryptographic Information andFlow Control,” filed on Oct. 15, 1999 by WACK et al.; Ser. No.10/035,817, entitled “Electronically Signing a Document,” and filed onOct. 25, 2002 by SCHEIDT et al.; Ser. No. 10/060,039, entitled “MultipleFactor-Based User Identification and Authentication,” filed on Jan. 30,2002 by SCHEIDT et al.; and Ser. No. 10/060,011, entitled “MultipleLevel Access System,” filed on Jan. 30, 2002 by SCHEIDT et al.

TECHNICAL FIELD

The present invention relates to cryptographic systems, and to methodsof encrypting telecommunication between a transmit space and a receivespace. In particular, the present invention relates to a system forformulating cryptographic keys used to encrypt plaintext messages orembedded objects and decrypt ciphertext communications media, and to thetransmission of voice and data in encrypted form, including among morethan two parties, and the selective reception and decryption of thatvoice and data.

BACKGROUND ART

In the modern world, communications are passed between parties in avariety of different ways utilizing many different communications media.Electronic communication is becoming increasingly popular as anefficient manner of transferring information, and electronic mail inparticular is proliferating due to the immediacy of the medium. Anothercommunications medium at the software program level defines an object asa particular piece of compiled code that provides a specific servicewithin the overall system.

Unfortunately, drawbacks accompany the benefits provided by electroniccommunication, particularly in the area of privacy. Electroniccommunications may be intercepted by unintended recipients. Wirelesstransmissions, such as voice communication by cellular telephone, andelectronic mail are especially susceptible to such interception. Also,the retention of information on a computing system may raise otherprivacy issues. Multiple users on a common computing device andseparation of information for multiple applications for a network ofusers communicating different categories of information are among thescenarios for which privacy may be a concern. In another context, theidea of privacy may extend beyond keeping information from prying eyes;the integrity of software program objects may be a concern. Themanipulation or other modification of an object can cause resultsunintended by the creator of the object.

The problem of electronic communication privacy has been addressed, andsolutions to the problem have been put in place. One form of solutionuses cryptography to provide privacy for electronic communication.Cryptography involves the encrypting or encoding of a transmitted orstored message or object, followed by the decryption or decoding of areceived or retrieved message or object. The message or object usuallytakes the form of a digital signal, a digitized analog signal, or afunctionality of the object. If the communication is intercepted duringtransmission or is extracted from storage by an unauthorized entity, themessage is worthless to the interloper, who does not possess the meansto decrypt the encrypted message.

In a system utilizing cryptography, the encrypting side of thecommunication incorporates an encoding device or encrypting engine. Theencoding device accepts the plaintext (unencrypted) message (or object)and a cryptographic key, and encrypts the plaintext message (or object)with the key according to an encrypt relation that is predetermined forthe plaintext communication and the key. That is, the message or objectis manipulated with the key in a predetermined manner set forth by thetext/key relation to produce a ciphertext (encrypted) message or object.

Likewise, the decrypting side of the communication incorporates adecoding device or decrypting engine. The decoding device accepts theciphertext message (or object) and a cryptographic key, and decrypts theciphertext message with the key according to a decrypt relation that ispredetermined for the ciphertext message (or object) and the key. Thatis, the message (or object) is manipulated with the key in apredetermined manner set forth by the text/key relation to produce a newplaintext message that corresponds with the original plaintext message.

The manner in which the key and the relation are applied in thecommunication process, and the manner in which keys are managed, definea cryptographic scheme. There are many conventional cryptographicschemes in use today. For example, probably the most popular of these isa public-key cryptographic scheme. According to a scheme of this type,the keys used are actually combinations of a public key component thatis available to anyone or to a large group of entities, and a privatekey component that is specific to the particular communication. Suchpublic-key schemes have been described extensively in the relevanttechnical literature, most notably by Martin E. Hellman, Bailey W.Diffie, and Ralph C. Merkle (see, for example, U.S. Pat. No. 4,200,770and No. 4,218,582, collectively referred to herein as “theDiffie-Hellman scheme”).

An important consideration in determining whether a particularcryptographic scheme is adequate for the application is the degree ofdifficulty necessary to defeat the cryptography, that is, the amount ofeffort required for an unauthorized person to decrypt the encryptedmessage. One way to improve the security of the cryptographic scheme isto minimize the likelihood that a valid key can be stolen, calculated,or discovered. The more difficult it is for an unauthorized person toobtain a valid key, the more secure communications will be under aparticular scheme.

DISCLOSURE OF THE INVENTION

It is therefore an objective of the present invention to provide aprocess and apparatus for assembling keys which provides added securityagainst compromising a communications medium, which may include softwarecomponent objects, by unauthorized entities.

It is a further objective of the present invention to provide a processand apparatus for developing key components that cannot be reproduced byunauthorized parties.

The invention has at least the following further objectives:

-   -   a. to advance the implementation of public key usage with access        control through symmetric encryption;    -   b. to adapt Constructive Key Management (“CKM”, as described        herein) for use with a transmission medium;    -   c. to use public and CKM key methodologies to establish a        private link or a conference capability for voice or data using        an analogue or digital telephone, or from a telephone to a        computing base such as the Internet;    -   d. to add an error detection field to a conference encryption        setup to ensure data integrity and to facilitate a quicker        encryption connection between telephones;    -   e. to provide a method for session keys to be securely        established between two telephones;    -   f. to use a portable voice and data encryption platform that        consists of a voice and/or data module, and encryption and        control module, and a modem module; and    -   g. to provide a viewing module, such as an LED, on the platform,        to present a visual confirmation of the number of other platform        users that are to be included in the encryption process, and to        identify a platform user by a number that can be confirmed by        the sender as an authentication feature.

These and other objectives and advantages are provided by acryptographic key split combiner, which includes a number of key splitgenerators for generating cryptographic key splits and a key splitrandomizer for randomizing the cryptographic key splits to produce acryptographic key. Each of the key split generators generates key splitsfrom seed data. The source of the seed data can be a pseudorandom orrandom data sequence that may be included in a key management schemethat uses the key splits for determining the data cryptographic orsession key. The management of the key splits can include provision of asource for the seed data and a distribution process to ensure that thedesired combination of key splits is generated.

In one embodiment of the present invention, the key split generatorsinclude a random split generator for generating a random key split basedon reference data. The random split generator may generate a randomsequence based on the reference data, or may generate a pseudorandomsequence based on the reference data. The random key split may furtherbe based on chronological data. The random key split may instead bebased on the reference data and on static data, which may be updated.One manner of updating the static data is by modifying a prime numberdivisor of the static data.

Other key split generators may include, for example, a token splitgenerator for generating a token key split based on label data and/ororganization data and/or static data; a console split generator forgenerating a console key split based on maintenance data, whetherprevious or current, and/or on static data; an asymmetrical key splitgenerator for generating pair-wise data; and a biometric split generatorfor generating a biometric key split based on biometric data, which mayinclude biometric data vectors and on biometric combiner data, and/orstatic data. The label data may be associated with label categories andsub-categories of addressees, which are meaningful to a user who isspecifying or determining the intended recipients(s) of the encryptedinformation or object. The label data may be read from a storage medium,and may include user authorization data. The resulting cryptographic keymay be, for example, a stream of symbols, at least one symbol block, ora key matrix.

An asymmetrical key split generator may be used to ensure the integrityof one or more of the key split generators, such as the random keysplit, or to ensure the integrity of the sender's data.

The key split generators may be used to determine which, if any, methodsand properties are allowed in a software program that includes componentobjects. A component object is a compiled piece of software code incomputer memory, which has an array of memory addresses, and indicatesrelatively where in memory certain functions or methods and data orproperties of that object are stored. An array associated with thecomponent object may use key splits which determine which methods andproperties are allowed and control access to the memory address forthose allowed methods and properties.

The present invention also includes a process for forming cryptographicor session keys, which includes generating a plurality of cryptographickey splits from seed data and randomizing the cryptographic key splitsto produce a cryptographic key. The process can include generatingreference pointers to the key splits that would facilitate the selectionof key splits during the encrypting or decrypting process. Once the dataor object is encrypted, these pointers can be included with theciphertext.

The cryptographic key splits may include, for example, a random keysplit based on reference data, a token key split based on label data, aconsole key split based on maintenance data, and a biometric key splitbased on biometric data. These key splits may be random sequences orpseudorandom sequences.

Generating the random key split may include generating a key split basedon the reference data and on chronological data, or based on thereference data and on static data. Generating the token key split mayinclude generating a key split based on the label data, which may beread from a storage medium and may include authorization data, and onorganization data, or based on the label data and on static data.Generating the console key split may include generating a key splitbased on previous maintenance data and on current maintenance data, orbased on the maintenance data and on static data. Generating thebiometric key split may include generating a key split based onbiometric data vectors and on biometric combiner data, or based on thebiometric data and on static data.

The static data provided for any of the key splits may be updated.Updating the static data may include modifying a prime number divisor ofthe static data.

The resulting cryptographic or session key may be a stream of symbols,at least one symbol block, or a key matrix.

According to a further aspect of the invention, a portable voice anddata encryption platform is provided for use with telephone, cellular,or satellite devices to transmit voice and data in encrypted form. Acontrol logic that is part of the platform manages the analog and datasequence. See Crowley et al. An information channel between two or moretelephones, two or more faxes, or two or more computers is establishedwith an initial public key exchange that securely distributes CKM keyfragments. The public keying material may be established on-the-fly withonly pre-computed and distributed parameters common among the parties ofthe information channel; in such cases, there is no data or key recoverycapability, and the session public keying fragments are generated andexchanged immediately prior to the session. A set of a private linklabel and a conference label that consists of a random or pseudo-randomnumber is concatenated to a session random number that results in acombined label and random number used for the session key. The combinedsession key results in an identical complete key used to encrypt ordecrypt the voice or data. The choice of either label depends on theuser's selection for a two-party link or for a conference call that maybe either a casual or collective call. The combined conference sessionkey is appended with an error detection field that is mathematicallycalculated based on the session key.

The implementation of public key usage with access control is providedthrough symmetric encryption, wherein the public key may be based onknown algorithms, such as Diffie-Hellman or Elliptical Curve algorithms.Constructive Key Management is adapted for use with a transmissionmedium. Diffie-Hellman focuses on pre-position key fragments, thebuilding of a session key from these fragments, and the use of labelsmanifested through key fragments that are used to add the variablerandom function that is part of the session key. The label key fragmentsmay be symmetric or asymmetric depending on whether there is an enforcedread/write requirement through software (symmetric) or throughencryption (asymmetric). The number of bits for a label and the randomnumber is dependent on the selected digital encryption algorithm (forexample, the Data Encryption Standard may be used). Public and CKM keymethodologies are used to establish a private link or a conferencecapability for voice or data using an analogue or digital telephone, orfrom a telephone to a computing base such as the Internet. An errordetection field is added to a conference encryption setup to ensure dataintegrity and to facilitate a quicker encryption connection betweentelephones. A method is provided for session keys to be securelyestablished between two telephones. A portable voice and data encryptionplatform is used, which consists of a voice and/or data module, andencryption and control module, and a modem module (see Crowley et al.).The platform may consist of a device that is connected between thehandset and phone instrument (in this case, an analog voice is convertedto digital, the digital block data is encrypted, and the resultantencrypted data is converted back to analog to be switched within a POTSnetwork). A viewing module, such as an LED, is available with theplatform. The LED can be used to present a visual confirmation of thenumber of other platform users that are to be included in the encryptionprocess. The LED can also identify a platform user by a number that canbe confirmed by the Sender as an authentication feature.

BRIEF DESCRIPTION OF DRAWINGS

The present invention will be more completely understood by way of thefollowing detailed description, with reference to the followingdrawings, wherein:

FIG. 1 shows a block diagram of a communications event featuringcryptography.

FIG. 2 is a block diagram of a key split combiner.

FIG. 3 is an exemplary hardware implementation of the key generationaspect of the present invention.

FIG. 4 shows an exemplary communication protocol for a two-party call.

FIG. 5 shows an exemplary communication protocol for a broadcastconference call.

BEST MODES FOR CARRYING OUT THE INVENTION

Referring to FIG. 1, a communication has an origination space 2 and adestination space 4. The origination space 2 defines the place and timeat which the communication originates. The destination space 4 definesthe place and time at which the communication is intended to be decoded.The origination space 2 and the destination space 4 may be remote inlocation. Alternatively, they may be collocated but displaced in time.The space and time correspondence between the origination space 2 andthe destination space 4 depends on the nature of a particularcommunication. The origination space 2 and destination space 4 arecoupled to a common communications channel 6. This communicationschannel 6 may bridge a physical space, such as empty air in the case ofa cellular voice telephone call. Alternatively, the communicationschannel 6 may be temporary storage for the communication while timepasses between the origination space 2 and the destination space 4, suchas a message left in memory on a computer by a first user, for a seconduser to read at a later time on the same computer. The communicationschannel 6 may also be a combination of the two, such as telephone cablesand storage memory in the case of an electronic mail transmission. Thecommunications channel 6 may also be a component object in computermemory.

A component object is a compiled piece of software code in computermemory, which has an array of memory addresses, and indicates relativelywhere in memory certain functions or methods and data or properties ofthat object are stored. An application programmer makes use of thecomponent object by obtaining a pointer to the memory that contains thearray. This is known in the art as creating an instance of a componentobject. The programmer can then make use of the methods and propertiesof the component object by indirectly addressing them via the array.

At the origination space 2, the original plaintext message 8 is receivedand encrypted according to the encrypt text/key relation 14, using aprovided encrypt key 10, to create a ciphertext message 16. Theciphertext message 16 is received at the destination space 4 via thecommunications channel 6. An authorized entity having a proper decryptkey 20 can then provide the decrypt key 20 to the destination space 4,where it is applied to the ciphertext message 16 according to a decrypttext/key relation 22 to create a new plaintext message 24 whichcorresponds to the original plaintext message 8.

The origination space 2 and the destination space 4 can be, for example,computers, or even the same computer. An exemplary computer may have acertain amount of storage space in the form of memory for storing thetext/key relation. A microprocessor or similar controller, along with acontrol structure and random access memory for storing originalplaintext and keys provided by a user, can be included in each space andcan perform the functions of the encryption/decryption engine. An inputdevice 26, 28, such as a keyboard, floppy disk drive, CD-ROM drive, orbiometrics reader, can also be provided for accepting the key andplaintext message from the origination user, and the key from thedestination user. At the destination space 4, an output device 30, suchas a monitor, disk drive, or audio speaker, may also be provided topresent the new plaintext message to the destination user. The text/keyrelation can be stored on a floppy disk or other permanent or temporaryportable storage, rather than in hard storage in the computer, to allowdifferent text/key relations to be applied by different users or indifferent situations.

The keys that are provided at the origination space and at thedestination space may be composed of several components, or splits, eachof which may be provided by a different source. As shown in FIG. 2, arandom key split 32 may be randomly or pseudorandomly generated. Asecond split 34 may be stored on a token. A third split 36 may be storedon a console, and a fourth split 38 may be provided by a biometricsource. The key splits may be combined to form a complete cryptographickey. This key may take the form of a stream of symbols, a group ofsymbol blocks, an N-dimensional key matrix, or any other form usable bythe particular encryption scheme.

The random split 32 provides a random component to the cryptographickey. This split 32 is randomly or pseudorandomly generated based on aseed which is provided by any source as reference data 40. For example,when a user attempts to log on to a system, the date and time of theuser's log-on attempt, represented in digital form, can be used as aseed to generate the key split. That is, the seed may be provided to apseudorandom sequence generator or other randomizer to produce therandom split. Such pseudorandom sequence generators are well known inthe art. For example, a simple hardware implementation could include ashift register, with various outputs of the register XORed and theresult fed back to the input of the register. Alternatively, the seedmay be combined, or randomized, with a built-in component 42, such as afixed key seed stored at the origination space. The randomization may beperformed, for example, by applying a variation of the text/key relationto the generated seed and the stored fixed key seed. This result may befurther randomized with, for example, a digital representation of thedate and time of the encryption 44, in order to produce the random keysplit 32.

The token split 34 may be generated in a similar fashion. In this case,the seed is provided on a token, that is, it is stored on a medium thatis possessed by the user. For example, the seed may be stored on afloppy disk that the system must read as part of the encryptionprocedure. The token may store a number of different seeds, or labeldata 46, each of which corresponds to a different authorization providedby the system or specified by the user. For example, one seed may beused to generate a key split to authorize a particular user to read amessage at a particular destination space. Another key seed may be usedto generate a key split to authorize any member of a group of users toread a message at any destination space, and for one particular user toread the message and write over the message at a particular destinationspace. The label data 46 may even designate a window of time duringwhich access to the communication is valid. This seed may be randomizedwith a built-in component 48, such as a seed stored at the originationspace, which may then be further randomized with organization data 50provided to the organization to which the user belongs.

The console split 36 is derived from a changing value stored at a userspace, such as on a system console. Maintenance data, such as thechecksum taken from a defragmentation table set, may be used to producesuch changing values. For example, the current maintenance data 52 maybe randomized with particular previous maintenance data. Alternatively,all previous maintenance data 54 may be randomized with a built-incomponent 56 stored at the origination space, the results of which areXORed together and randomized with the current maintenance data 52. Therandomization result of the changing value is the console split 36.

The biometric split 38 is generated from biometric data vectors 58provided by biometric samples of the user. For example, a retinalscanner may be used to obtain a unique retinal signature from the user.This information, in digital form, will then be used to generate thebiometric split 38. This may be accomplished by, for example,randomizing a digital string corresponding to the biometric vectors 58with biometric combiner data 60, which may be a digital hash of theuser's system identification number or some other identifying data thatcan be linked to the user's physical data provided by the biometricreader. The resulting randomized data is the biometric split 38. Thebiometric split 38 provides information that is incapable of beingreproduced by anyone but the user providing the biometric data vector58.

The built-in key split components 42, 48, 56 described herein may bestatic in that they do not change based on uncontrolled parameterswithin the system. They may be updated for control purposes, however.For example, the built-in key split components 42, 48, 56 may be changedto modify the participation status of a particular user. The key splitcomponent may be changed completely to deny access to the user.Alternatively, only a single prime number divisor of the original keysplit component may be taken from the key split component as amodification, in order to preserve a legacy file. That is, the user willbe able to access versions of the file created prior to themodification, but will not be allowed to change the file, effectivelygiving the user read-only access. Likewise, modification of the keysplit component can be effected to grant the user broader access.

According to one cryptographic scheme that may be used in accordancewith the present invention, a prime number and a random number aregenerated from a data seed source for one or more of the communicatingparties. The random number can be used in the “public” domain, such ason a public server, or may be negotiated between the parties prior tothe communications process. To establish communications between twoparties, a polynomial or modulo calculation is made of the sender'sprime number and the recipient's random number for the sender. Therecipient calculates the recipient's prime number and the sender'srandom number. The two-way calculation creates a cryptographic orsession key that is used to encrypt the random key split or encrypt ahash of the transmitted or stored message, thereby creating anasymmetrical split 64. The other key split generators that are used forthe encrypting side of the communications provide integrity to theasymmetrical key split generator.

Once the key splits 32, 34, 36, 38 have been generated, they may berandomized together to produce the cryptographic key 62 for thecommunication. In performing each combination to generate the completecryptographic key, a different variation of the text/key relation may beapplied. The use of a plurality of different text/key relationvariations adds to the security of the overall cryptographic scheme. Itis contemplated that key splits other than those specifically describedherein may be combined in forming the complete key 62. The total numberof splits may also vary, and these splits may be used to build a keymatrix to add to the complexity of the system. This complete key 62should be in a form suitable for use in the particular cryptographicscheme. That is, different fields in the key may have differentfunctions in the protocol of the communication, and should be arrangedaccordingly within the key.

At the destination space, the process is reversed in order to determinewhether a user attempting to access a message has authorization, thatis, has the valid key. The key supplied by the user at the destinationspace must include information required by the labels that were used tocreate the token split at the origination space. This information mayalso take the form of a token split. Further, a biometric split may berequired as part of the destination key, in order to provide a linkbetween assigned identification data for the user and physical datacollected from the user biometrically. The token split and the biometricsplit may be combined with other splits at the destination space to formthe complete destination key.

FIG. 3 shows an exemplary hardware implementation for generating andmanaging the keys according to the present invention.

In the case of component object control, the array of addresses can beencrypted in the executable file of the component object. Theapplication program using the component object can then call a special“create instant” function to pass along key splits or labelrepresentations. The “create instant” will: 1) using the key splits,determine which, if any, methods and properties are allowed, based onthe passed key splits; 2) decrypt the memory address for those allowedmethods and properties; and 3) modify the addresses of the methods andproperties that are not allowed, thereby to instead call a “stub”function which will return an error code corresponding to thedetermination of no authorization. Note that there is no attempt toencrypt application data as it is passed to and from the componentobject.

The following description relates to use of the described methodologyfor provision of a private voice or data link, or for provision ofconference capability.

The Process

A public key establishment is used based on Diffie-Hellman keyagreement. Each platform device is loaded with a universal (common) setof Diffie-Hellman parameters designated as P, Q, and G. From theseparameters, a public/private pair of public key fragments can begenerated by each platform. A random or pseudo-random number generationand storage capability exists with each platform. A pair of CKM labels(ID number and random number per label) can be generated by eachplatform.

One of the platform users is designated as the Sender (S) to initiateand manage the encryption exchange among one or more of other platformusers.

Two Party Call (FIG. 4)

-   -   1. A plain text call is initiated between two platform users.    -   2. One of the users states that he/she is S; a “secure private”        button may be pressed to activate the encryption process. The        receiving user's platform, R, will automatically sense an        initiation and respond sequence as follows (see Figure One for        math process):        -   a. S tells R that he is going secure. S presses the “secure”            button. A coded signal is sent to R that is visually            displayed on the R LED that a secure exchange has been            initiated. An automated process proceeds.        -   b. S creates a Diffie-Hellman asymmetric key pair from the            common P, Q, and G parameters, generates a Net label,            generates a Private label, and generates a random number.        -   c. R generates a Diffie-Hellman asymmetric key pair from the            common P, Q, and G parameters.        -   d. R sends the public part of the asymmetric key pair to S.        -   e. S computes the Diffie-Hellman shared key from the public            part of R's asymmetric key pair and encrypts the Net label,            Private label, and random number with the shared key.        -   f. S sends the encrypted Net label, Private label, and            random number and also the public key part of S's own            Diffie-Hellman asymmetric key to R.        -   g. R computes the Diffie-Hellman shared key from the public            key part of S's Diffie-Hellman asymmetric key pair.        -   h. R decrypts the labels and random number from S using the            Diffie-Hellman computed shared key.        -   i. A respective identification number is exchanged and            received at both platforms. Either one or both users can do            a verbal confirmation of the number via the telephone.        -   j. A cancel button or an equivalent is done to break the            call.            A Casual Conference Call

The encryption process for the casual conference call is similar to theTwo Party call in that a plain text call is initiated between twoplatform users. A “secure” exchange is completed between the two usersas defined in the two party call.

During the phone call exchange, it is decide by one of the parties thatan additional user is desired to join the conversation or data exchange.The following steps are done to establish the new user, R1, to theencrypted exchange (see Figure Two for math process).

-   -   a. S presses the “hold button with R” that suspends the        encrypted channel with R but maintains encryption        synchronization. The S LED confirms that R is on hold.    -   b. S establishes a POTS connection with R1.    -   c. S tells R1 he is going secure. S presses the “secure” button.        A coded signal is sent to R1 that a secure exchange is being        initiated; also an LED confirmation is done through the R1 LED.        Since there is only one party present, a communication protocol        between both parties determines that this is not a broadcast        conference call.    -   d. S generates a Private label (between S and R1) and a        Diffie-Hellman asymmetric key pair and sends the public part to        R1.    -   e. R1 generates a Diffie-Hellman asymmetric key pair from the        common P, Q, and G parameters and computes the Diffie-Hellman        shared key from the public key part from S. R1 sends the public        part of the key pair to S.    -   f. S computes the Diffie-Hellman shared key from the public key        of R1.    -   g. S encrypts the private label, the Net label that was        established with R, and the random number established with R and        sends this to R1. S retains the private label.    -   h. R1 decrypts the data from S and retains the Private label.    -   i. S presses the “hold button with R1” that suspends the        encrypted channel with R but maintains encryption        synchronization. The S LED confirms that R and R1 are on hold as        private conversations.    -   j. S presses the “Conference button”. A coded signal is sent to        R and R1 that a conference call is being initiated. A        confirmation is done with each R and R1 LED's. S generates a Net        label and a new random number.    -   k. First, S sends, encrypted with R's public key portion, the        Net label concatenated with a new random number. An error        detection scheme such as a CRC is applied to the combined Net        Label and random number; the resultant error detection data is        included in the transmission with the label and random number. R        receives the data, does a CRC on the data and confirms the data,        and decrypts the Net label and a random number with the private        portion of the Public key.    -   l. All three users have a common Net label and common random key        from S. A secure conference call may begin.    -   m. Note: a private conversation may be resumed with either R or        R1 by placing the conference call on hold and initiating a        secure call.    -   n. A Cancel button or an equivalent process is done to break the        call.        A Broadcast Conference Call (FIG. 5)

The encryption process differs from the casual conference call in thatall parties to the conference are available at one time, and securerelationship is established while all the parties are present. Thebroadcast conference call uses the process of the casual conference callbut with a slight change in the sequence (see Figure Three for mathprocess).

After all the parties are connected and confirmed present, one of theparties states that he/she is S:

-   -   a. S presses the “secure” button. A coded signal is sent to all        other parties present that a secure exchange is being initiated;        also an LED confirmation is activated for all the conference        call party LED's. A communication protocol is established to        activate the secure process in a mutually determined order for        each of the conference parties present.    -   b. Each party completes an exchange with S as follows:        -   1. S generates a Net label, Random number and a            Diffie-Hellman asymmetric key pair using common P, Q, and G            parameters and sends the public part to R.        -   2. R generates a Private label (for use between R and S) and            a Diffie-Hellman asymmetric key pair from the common P, Q,            and G parameters. R computes the Diffie-Hellman shared key            from the S's public key. R encrypts the Private label with            the shared key. R sends the public key part of his or her            asymmetric key pair to S. R also sends the encrypted Private            label for R and S.        -   3. S computes the Diffie-Hellman shared key from the public            key from R. S decrypts the Private label with the shared            key. S retains the Private label.        -   4. S encrypts the Net label and Random number with the            shared key and sends this to R. A CRC is done on the            encrypted concatenated numbers, and the CRC number is sent            with the encrypted concatenated numbers.        -   5. R receives and decrypts the Net label and Random number            with the computed shared key. R retains these.        -   6. S presses the “hold button with R that suspends the            encrypted channel with R but maintains encryption            synchronization. The S LED confirms that R is on hold.        -   7. R1, and the balance of parties to the conference call            would do the above b1 through b6 processes. The LED of S            would reflect which of the parties have successfully            complete a base secure exchange.    -   c. S presses the “Conference button”. A coded signal is sent to        all parties that a conference call is being initiated. A        confirmation is done with each party's LED. S generates a Net        label and a random number.    -   d. S sends, encrypted with R's public key portion, the        concatenated Net label and random number. S repeats the process        with each party to the conference call. The LED of S would        reflect which of the parties have been sent the net data.    -   e. All parties to the conference call have a common Net label        and a common random key from S. A secure conference call may        begin by using the keying material with an encryption algorithm.    -   f. Note; a private conversation may be initiated with any of the        parties and S by placing the conference on hold and establishing        a secure two party call.    -   g. S presses a Cancel button or an equivalent process to break        the conference call.

The invention has been described using exemplary and preferredembodiments. However, the scope of the present invention is not limitedto these particular disclosed embodiments. To the contrary, the presentinvention is contemplated to encompass various modifications and similararrangements The scope of the claims, therefore, should be accorded thebroadest interpretation so as to include all such modifications andsimilar arrangements.

1. A method of establishing a secure communication channel, comprising:sending, by a first party a secure call notification to a second party;accessing, by the first and second parties, base, prime, and sub-primeparameters; generating, by the second party, a second asymmetric keypair comprising a second public key and a second private key, based onthe base, prime, and sub-prime parameters; sending, by the second partyto the first party, the second public key; generating, by the firstparty, a net label, a private label, a random value, a first asymmetrickey pair comprising a first public key and a first private key based onthe base, prime, and sub-prime parameters, and a shared key based on thesecond public key; encrypting, by the first party, the net label, theprivate label, and the random value, using the shared key; sending, bythe first party to the second party, the encrypted net label, theencrypted private label, the encrypted random value, and the firstpublic key; generating, by the second party, the shared key based on thefirst public key; decrypting, by the second party, the encrypted netlabel, the encrypted private label, and the encrypted random value usingthe shared key; and exchanging, by the first and second parties,respective identification numbers to establish the secure communicationchannel; wherein the secure call notification is a first secure callnotification, the net label is a first net label, the private label is afirst private label, the random value is a first random value, theshared key is a first shared key, the encrypted net label is a firstencrypted first net label, the encrypted private label is a firstencrypted first private label, and the encrypted random value is a firstencrypted first random value further, the method further comprising:designating, by one of the first party and the second party, either ofthe first party and the second party as a sender, and the other of thefirst party and the second party as a non-sender; suspending, by thesender, the secure communication channel between the first party and thesecond party; establishing, by the sender, a communication channel witha third party; sending, by the sender, a second secure call notificationto the third party; accessing, by the third party, the base, prime, andsub-prime parameters; generating, by the third party, a third asymmetrickey pair comprising a third private key and a third public key, based onthe base, prime, and sub-prime parameters; sending, by the third partyto the sender, the third public key; generating, by the sender, a secondprivate label, a second net label, a second random value, a fourthasymmetric key pair comprising a fourth public key and a fourth privatekey based on the base, prime, and sub-prime parameters, and a secondshared key based on the third public key; encrypting, by the sender, thesecond private label, the first net label, and the first random value,using the second shared key, to provide an encrypted second privatelabel, a second encrypted first net label, and a second encrypted firstrandom value; sending, by the sender to the third party, the encryptedsecond private label, the second encrypted first net label, the secondencrypted first random value, and the fourth public key; generating, bythe third party, the second shared key based on the third public key;decrypting, by the third party, the encrypted second private label, thesecond encrypted first net label, and the second encrypted first randomvalue, using the second shared key; suspending, by the sender, thesecure communication channel between the sender and the third party;sending, by the sender to the third party and the non-sender, aconference call notification; encrypting, by the sender, the second netlabel and the second random value, using one of the first public key andthe second public key, to provide a first encrypted second net label anda first encrypted second random value; generating, by the sender, afirst error detection value for the first encrypted second net label andthe first encrypted second random value; sending, by the sender to thenon-sender, the first encrypted second net label, the first encryptedsecond random value, and the first error correction value; generating,by the non-sender, a second error detection value, for the firstencrypted second net label and the first encrypted second random value;checking, by the non-sender, the validity of the first encrypted secondnet label and the first encrypted second random value by comparing thefirst and second error detection values; decrypting, by the non-sender,the first encrypted second net label and the first encrypted secondrandom value, using one of the first private key and the second privatekey; encrypting, by the sender, the second net label and the secondrandom value, using the third public key, to provide a second encryptedsecond net label and a second encrypted second random value; generating,by the sender, a third error detection value, for the second encryptedsecond net label and the second encrypted second random value; sending,by the sender to the third party, the second encrypted second net label,the second encrypted second random value, and the third error correctionvalue; generating, by the third party, a fourth error detection value,for the second encrypted second net label and the second encryptedsecond random value; checking, by the third party, the validity of thesecond encrypted second net label and the second encrypted second randomvalue by comparing the third and fourth error detection values; anddecrypting, by the third party, the second encrypted second net labeland the second encrypted second random value, using third private key.2. A method of establishing a secure communication channel, comprising:establishing a communication link among at least three partiescomprising a first party and other parties; sending, by the first party,a broadcast conference call notification to the other parties;accessing, by the first party and the other parties, base, prime, andsub-prime parameters; generating, by the first party, a net label, arandom value, and a first asymmetric key pair comprising a first publickey and a first private key based on the base, prime, and sub-primeparameters; sending, by the first party, the first public key to each ofthe other parties; generating, by each of the other parties, arespective private label, a respective other asymmetric key paircomprising a respective other public key and a respective other privatekey based on the base, prime, and sub-prime parameters, and a respectiveother shared key based on the first public key; encrypting, by each ofthe other parties, the respective private label using the respectiveshared key; sending, by each of the other parties, the respectiveencrypted private label and the respective other public key to the firstparty; computing, by the first user, each respective shared key fromeach respective public key sent by the other parties; decrypting, by thefirst party, each respective encrypted private label using therespective shared keys; respectively encrypting, by the first user, thenet label and the random number, using the respective shared keys;sending, by the first party, the respective encrypted net labels and therespective encrypted random values to the respective other parties;decrypting, by the other parties, the respective encrypted net labelsand the respective encrypted random values using the respective sharedkeys; and establishing, by the first user and the other users, thesecure communication channel using the net label and the random value.3. The method of claim 2, further comprising: deriving, by the firstparty, an error checking code for each of the respective other partiesfrom the respective encrypted net labels and the respective encryptedrandom values; sending, by the first party, the respective errorchecking codes to the respective other parties; and confirming, by theother parties, validity of the respective encrypted net labels and therespective encrypted random values using the respective error checkingcodes.